vendredi 17 octobre 2025

Brève histoire des technologies de virtualisation : Xen, VMware, KVM, et QEMU

Par Damien Clauzel, vendredi 17 octobre 2025. Informatique

Remarque liminaire : ce document est une ressource pédagogique créée pour mes élèves, je la publie ici via une conversion brutale pour DotClear.

  • Lecteurs ciblés : Master 2 en informatique
  • Connaissances prérequises :
    • architectures matérielles
    • technologies des systèmes d’exploitation

Brève histoire des technologies de virtualisation : Xen, VMware, KVM, et QEMU [1]

Contexte

L’évolution des technologies de virtualisation sur architecture x86 représente l’un des aspects les plus significatifs de l’informatique moderne. Son histoire illustre comment les contraintes architecturales du processeur x86 ont conduit au développement de nouvelles solutions, puis de nouveaux paradigmes. Les quatre technologies abordées ici — Xen, VMware, KVM et QEMU - ont chacune apporté des approches distinctes pour résoudre les problèmes fondamentaux de la virtualisation x86. L’aboutissement actuel étant l’informatique par l’approche du nuage.

En complément de ces aspects techniques, la virtualisation répond aussi à des motivations économiques et opérationnelles fortes : consolidation des serveurs physiques, réduction des coûts d’infrastructure, meilleure résilience, flexibilité de déploiement… Mais tout ça on s’en fout ici.

Le défi fondamental de la virtualisation x86 : les anneaux de protection et leurs contraintes

Rappel : l’architecture x86 implémente un système de protection à quatre niveaux, appelés « anneaux de protection » (nommés de ring 0 à ring 3). Les systèmes d’exploitation non-ésotériques utilisent principalement deux de ces anneaux : le ring 0 pour l’espace noyau (kernel space) avec les privilèges maximaux, et le ring 3 pour l’espace utilisateur (user space) avec des privilèges restreints (1, 2) . Cette organisation hiérarchique garantit l’isolation et la sécurité du système en empêchant les applications utilisateur d’accéder directement aux ressources matérielles critiques.

Le problème fondamental de la virtualisation x86 réside dans l’existence d’instructions sensibles non privilégiées. Selon les critères de Popek et Goldberg (3, 4) , une architecture est virtualisable si toutes les instructions sensibles sont privilégiées. L’architecture x86 viole cette condition : certaines instructions se comportent différemment selon l’anneau d’exécution sans générer d’exception (trap). Ces instructions peuvent lire l’état du processeur ou modifier la configuration du système sans déclencher une interruption permettant à l’hyperviseur d’intervenir. C’est ce qu’on appelle pudiquement « le problème ».

Cette particularité architecturale signifie qu’un système d’exploitation conçu pour s’exécuter en ring 0 ne peut pas fonctionner correctement s’il est déplacé en ring 3 sans modifications. Les instructions privilégiées échoueront silencieusement ou produiront des résultats incorrects, compromettant la stabilité et la sécurité du système virtualisé.

La première solution : VMware et sa traduction binaire

VMware a été la première entreprise à résoudre efficacement pour la production — les geeks avaient déjà des trucs avant — le problème de virtualisation x86 avec une solution commerciale viable. L’approche appelée « traduction binaire dynamique » (dynamic binary Translation) (5, 6) représente une forme d’émulation partielle sophistiquée. Le système permet au code invité de s’exécuter directement sur le processeur physique dans la plupart des cas, mais intercepte et émule en logiciel les instructions problématiques.

La traduction binaire fonctionne en analysant dynamiquement le flux d’instructions du système invité. Lorsqu’une instruction sensible non privilégiée est détectée, l’hyperviseur VMware la remplace par une séquence d’instructions équivalentes qui produisent le même effet tout en maintenant l’isolation nécessaire. Cette technique permet d’exécuter des systèmes d’exploitation — même ésotériques — non modifiés avec des performances remarquables pour l’époque : 80 à 95 % des performances natives selon les mesures internes de VMware au début des années 2000.

Le succès commercial initial de VMware provient de cette capacité unique à virtualiser des systèmes invités sans modification, ouvrant la voie à l’adoption massive de la virtualisation dans les environnements d’entreprise.

QEMU : l’émulation universelle par compilation dynamique

Architecture et fonctionnement de QEMU

QEMU (Quick EMUlator), développé par Fabrice Bellard et publié en 2005, représente une approche radicalement différente basée sur la compilation dynamique à la volée (just in time) (7, 8) . Contrairement aux solutions précédentes qui se concentraient sur la virtualisation depuis x86 vers x86, QEMU vise l’émulation universelle permettant l’exécution de code d’une architecture sur une autre ; par exemple ARM sur x86-64 ou inversement.

Le cœur de QEMU utilise un Tiny Code Generator qui traduit dynamiquement les instructions de l’architecture source vers l’architecture cible. Cette traduction s’effectue par blocs d’instructions, avec mise en cache des blocs traduits pour optimiser les performances lors d’exécutions répétées. Cette approche décomposée permet la portabilité : QEMU peut émuler plus de 15 architectures différentes (ARM, MIPS, PowerPC…)

QEMU fonctionne selon deux modes principaux : l’émulation complète de système (system emulation) qui virtualise une machine complète (CPU, mémoire, et périphériques), et l’émulation utilisateur (user emulation) qui permet d’exécuter des applications compilées pour une architecture différente.

Impact sur l’écosystème de virtualisation

L’intérêt de cette polyvalence en fait un outil indispensable pour le développement cross-platform, les tests de compatibilité, et la recherche en architecture des processeurs.

Aussi, bien que QEMU soit initialement plus lent que les solutions spécialisées en raison de sa généralité, il est devenu un composant fondamental de l’écosystème moderne de virtualisation. La plupart des hyperviseurs libres (KVM, Xen, VirtualBox…) utilisent QEMU pour l’émulation des périphériques tout en déléguant la virtualisation CPU à des mécanismes plus efficaces. Cette architecture modulaire permet de combiner les avantages de différentes approches : performance native pour le CPU grâce aux extensions matérielles, et flexibilité maximale pour les périphériques grâce à QEMU.

Xen et le bond de la paravirtualisation

Conception et principes fondamentaux

Xen, développé à l’Université de Cambridge par Ian Pratt et Keir Fraser, a introduit en 2003 une approche orthogonale appelée paravirtualisation (9). Plutôt que d’émuler ou de traduire les instructions problématiques, Xen propose de modifier directement les systèmes d’exploitation invités pour qu’ils puissent s’exécuter efficacement en ring 3 tout en coopérant explicitement avec l’hyperviseur.

La paravirtualisation repose sur le remplacement des instructions sensibles dans le noyau du système invité par des hypercalls — des appels directs à l’hyperviseur similaires aux appels système (syscalls). Cette modification permet au système invité de fonctionner en ring 3 tout en conservant un accès contrôlé aux ressources privilégiées via l’hyperviseur qui s’exécute en ring 0. L’avantage majeur de cette approche est l’élimination quasi-complète du surcoût (overhead) de virtualisation : les performances sont typiquement de 95 à 98 % des performances natives. Le problème n’est plus alors les pénalités de la virtualisation des instructions, mais l’accès aux ressources matérielles partagées et externes : cartes filles, bus, etc.

Architecture Dom0/DomU [2] et la gestion des ressources

Xen implémente une architecture unique basée sur des domaines. Le Domain 0 (Dom0) est un domaine privilégié exécutant une version modifiée de Linux qui gère les pilotes matériels et fournit les services de gestion. Les Domains Unprivileged (DomU) sont les machines virtuelles standard qui s’exécutent sous contrôle de l’hyperviseur. Cette séparation permet une isolation robuste tout en maintenant la flexibilité nécessaire pour la gestion des ressources physiques.

L’inconvénient majeur de la paravirtualisation est sa limitation aux systèmes libres. Les noyaux propriétaires comme Windows NT à l’époque ne pouvaient pas être modifiés pour supporter les hypercalls, nécessitant l’utilisation de techniques d’émulation plus coûteuses. Cette limitation a restreint l’adoption de Xen dans les environnements mixtes Linux/Windows typiques des entreprises Heureusement, les choses ont changé pour le mieux : les systèmes d’exploitation propriétaires se sont ouverts, et QEMU est arrivé en renfort.

L’émergence des extensions matérielles

Le contexte Microsoft et les spécifications de sécurité

Le développement des extensions matérielles de virtualisation trouve en partie son origine dans les besoins de sécurité avancée de Microsoft. Lors du développement de Windows Vista, Microsoft travaillait sur le projet « Next-Generation Secure Computing Base (NGSCB) » (10, 11) , anciennement appelé « Palladium », visant à implémenter des fonctionnalités de gestion des droits numériques (DRM) au niveau matériel. L’idée était d’exécuter les composants de sécurité critique dans un environnement isolé, protégé même du système d’exploitation principal.

En parallèle, Intel et AMD développaient déjà leurs propres projets de virtualisation matérielle (« Vanderpool » et « Pacifica »). La collaboration avec Microsoft a accéléré l’adoption de ces extensions.

Technologies Intel VT-x et AMD-V

Les extensions « Intel VT-x » (Virtualization Technology) et « AMD-V » (AMD Virtualization) (12, 13) ont été introduites respectivement en 2005 et 2006. Ces technologies ajoutent un nouveau mode d’exécution au processeur, permettant à l’hyperviseur de s’exécuter dans un contexte privilégié (VMX root mode pour Intel) tandis que les systèmes invités s’exécutent dans un contexte non privilégié (VMX non-root mode) tout en conservant l’illusion d’un accès ring 0.

Ces extensions résolvent élégamment le problème des instructions sensibles non privilégiées en introduisant des VM exits automatiques. Lorsqu’une instruction sensible est exécutée par un système invité, le processeur transfère automatiquement le contrôle à l’hyperviseur qui peut alors émuler l’instruction ou effectuer l’action appropriée. Cette approche élimine le besoin de modification des systèmes invités (comme dans la paravirtualisation) ou de traduction binaire complexe (tel VMware)1415.

KVM : l’intégration native dans Linux

Développement chez Qumranet

KVM (Kernel-based Virtual Machine) a été développé par Avi Kivity chez Qumranet, une jeune-pousse israélienne fondée en 2005 (16, 17). L’objectif initial était de créer une solution de virtualisation de bureau permettant aux entreprises de déployer des postes de travail Windows virtualisés sur infrastructure Linux. Cette approche visait particulièrement les environnements d’activité nécessitant de nombreux postes standardisés (centre d’appel, filiale bancaire, etc.).

La stratégie de Qumranet était elle aussi à contre-pied : plutôt que de développer un hyperviseur indépendant (comme Xen), ils ont choisi d’intégrer directement les fonctionnalités de virtualisation dans le noyau Linux existant. Cette approche tire parti de toute l’infrastructure de Linux : gestion de la mémoire, ordonnancement, pilotes de périphériques, et système de fichiers. KVM augmente essentiellement Linux en hyperviseur natif par l’ajout d’un module noyau. Reste ensuite à gérer toutes les couches service et fonctionnelle, la sécurité, etc. Bref il vaut mieux avoir un OS dédié pour un usage non-individuel car une distribution Linux de bureau (ni même de serveur) ne peut pas être magiquement transformée en hyperviseur correctement sécurisé et proposant les fonctionnalités attendues des utilisateurs.

Architecture et intégration au noyau Linux

KVM a été intégré au noyau Linux en février 2007 avec la version 2.6.20. Cette intégration garantit la maintenance à long terme et l’évolution continue avec les améliorations du noyau Linux.

L’architecture de KVM exploite les extensions matérielles VT-x/AMD-V pour la virtualisation CPU, tout en s’appuyant sur QEMU pour l’émulation des périphériques. Cette combinaison offre des possibilités intéressantes : performances natives pour le processeur grâce au support matériel, et flexibilité maximale pour les périphériques grâce à l’écosystème riche de QEMU. Les machines virtuelles KVM apparaissent comme des processus Linux standard, bénéficiant automatiquement de toutes les fonctionnalités du noyau. Mais cette approche la rend aussi dépendante des évolutions et des limitations de Linux : KVM ne peut qu’ajouter du code, et non pas en supprimer ou en modifier. Il y a donc des pénalités à la surcharge, et des risques liés à la cohabitation avec le reste du code Linux, même s’il n’est pas utilisé par KVM.

L’évolution moderne et la convergence technologique

Adoption universelle des extensions matérielles

Aujourd’hui, tous les grands hyperviseurs modernes utilisent les extensions matérielles Intel VT-x et AMD-V pour la virtualisation CPU. Cette standardisation a éliminé des différences fondamentales entre les approches, créant une base technologique commune pour l’ensemble de l’industrie. Les performances de virtualisation atteignent désormais 95 à 99 % des performances natives pour la plupart des charges de travail, rendant la virtualisation transparente pour les utilisateurs finaux.

Parallèlement, l’approche paravirtualisée de Xen a été adoptée universellement pour les pilotes de périphériques. Les pilotes paravirtualisés (standard technique « virtio ») remplacent l’émulation matérielle traditionnelle par une interface optimisée entre invité et hyperviseur. Cette convergence technique illustre comment les meilleures idées de chaque approche ont été intégrées dans un modèle hybride optimal : extensions matérielles pour le CPU, drivers paravirtualisés pour les périphériques. Bon, ça c’est la version simple et rose, dans la pratique des industriels se tirent dans les pattes et verrouillent via les licences privatives de leurs systèmes.

Technologies avancées de virtualisation

Les hyperviseurs modernes intègrent des technologies sophistiquées bien au-delà de la virtualisation CPU basique. La Second Level Address Translation (SLAT), implémentée via Intel EPT (Extended Page Tables) et AMD NPT (Nested Page Tables), permet la virtualisation efficace de la mémoire en éliminant le surcoût (overhead) des tables de pages shadow. Les IOMMU (Input-Output Memory Management Unit) étendent la virtualisation aux périphériques, permettant l’accès direct des machines virtuelles aux cartes réseau et de stockage via des technologies comme SR-IOV.

Ces avancées apportent des cas d’usage savoureux comme le GPU passthrough pour les tâches spécialisées (traitement du signal, réseaux de neurones…), la virtualisation réseau pour les environnements dans le nuage, et l’isolation de sécurité pour les applications critiques. L’évolution vers le calcul confidentiel avec Intel Trusted Execution Technology (TXT) et AMD Memory Guard montre que les travaux de recherche et d’ingénierie sur la virtualisation continuent fortement. On constate également un rapprochement avec les mécanismes de conteneurisation, qui doivent quant à eux répondre à des enjeux connexes.

Applications contemporaines et spécialisations

Xen dans les systèmes embarqués et de sécurité

Xen a trouvé sa place dans des domaines spécialisés où ses caractéristiques uniques offrent des avantages distincts. Le mode Dom0less, introduit récemment, permet de démarrer des machines virtuelles directement sans nécessiter un domaine de contrôle Linux complet (18) . Cette fonctionnalité est particulièrement intéressante dans l’industrie automobile et les systèmes embarqués où les contraintes de mémoire et de temps de démarrage sont critiques.

Qubes OS utilise Xen pour implémenter un modèle de sécurité security by isolation où chaque application s’exécute dans une machine virtuelle dédiée. Cette approche offre une protection maximale contre les malwares et les attaques par compromission, au prix d’une complexité d’utilisation accrue. Et croyez-moi, c’est tellement chiant que vous n’avez pas envie de l’utiliser au quotidien.

Les systèmes critiques de défense et de recherche adoptent également Xen pour ses garanties d’isolation.

QEMU dans le développement et la recherche

QEMU est indispensable pour le développement cross-platform et la recherche en architecture des processeurs. Les développeurs utilisent QEMU pour tester leurs applications sur des architectures non disponibles physiquement, accélérant significativement les cycles de développement. La communauté de recherche en systèmes s’appuie sur QEMU pour prototyper de nouvelles architectures et évaluer des modifications matérielles sans nécessiter de fabrication de puces.

L’intégration de QEMU avec des frameworks de simulation (comme gem5) permet des analyses de performance détaillées et l’exploration d’architectures expérimentales. Cette capacité est cruciale pour la recherche académique et le développement de futurs processeurs dans l’industrie semiconductrice.

Il n’existe aujourd’hui pas d’alternative réelle à QEMU.

Comparaison simple de solutions modernes

Technologie Forces principales Cas d’usage typiques Surcoût en performances
KVM Intégration Linux native, écosystème riche Nuage, centres de données légers 2–5 %
VMware ESXi Maturité enterprise, outils de gestion Centres de données d’entreprise 3–7 %
Xen Isolation robuste, empreinte mémoire réduite Nuage, systèmes embarqués, sécurité critique 2–5 %
QEMU Émulation universelle, développement ''cross-platform'' Développement, recherche, émulation héritée 10–50 %

Leçons et perspectives d’évolution

L’histoire de la virtualisation x86 illustre comment les contraintes architecturales stimulent l’innovation technologique. Le manque de sécurité dans la conception des instructions sensibles non privilégiées de l’architecture x86 a conduit à un écosystème technologique diversifié, qui commence à rendre pénible le travail à cause de l’accumulation des couches historiques. Les nouvelles architectures (puces pour l’informatique mobile, Apple avec ses puces M*) peuvent laisser espérer de nouvelles approches natives. Bien sûr cela veut dire redévelopper des écosystèmes logiciels entiers, mais ça on sait faire.

Cette évolution souligne également l’importance de la collaboration entre logiciel et matériel. Les extensions VT-x/AMD-V résultent d’une coopération étroite entre les concepteurs de processeurs (Intel, AMD) et les développeurs de logiciels de virtualisation. Cette synergie continue de s’approfondir avec les technologies émergentes comme les enclaves sécurisées (Intel SGX) et le calcul confidentiel.

Ligne de temps : des étapes de la virtualisation x86 de 1974 à 2025

  • 1974 :
    • Gerald J. Popek et Robert P. Goldberg publient « Formal requirements for virtualizable third generation architectures », établissant les critères théoriques de la virtualisation
  • 1998 :
    • Fondation de VMware à Palo Alto ; environ 20 employés et développement discret
  • 1999 :
    • Lancement officiel de VMware
  • 2001 :
    • VMware entre sur le marché des serveurs avec VMware GSX Server (hébergé) et VMware ESX Server (bare-metal)
  • 2002 :
    • VMware lance ESX Server 1.5, son premier hyperviseur professionnel
    • Introduction de vMotion (migration à chaud de machines virtuelles), début de la haute disponibilité dans la virtualisation
  • 2003 :
    • Première publication de Xen : « Xen and the Art of Virtualization »
    • VMware lance vCenter Server pour la gestion centralisée
  • 2004 :
    • AMD annonce ses extensions de virtualisation sous le nom de code Pacifica (futur AMD-V/SVM)
    • Intel développe ses extensions Vanderpool Technology (futur VT-x)
    • Première conférence VMworld
  • 2005 :
    • Fabrice Bellard publie le papier QEMU à l’USENIX Annual Technical Conference
    • Intel sort les premiers processeurs VT-x (Pentium 4)
  • 2006 :
    • AMD lance les premiers processeurs AMD-V (Athlon 64)
  • 2007 :
    • KVM intégré au noyau Linux mainline avec la version 2.6.20
    • Avi Kivity publie « kVM: the Linux Virtual Machine Monitor » au Ottawa Linux Symposium
  • 2009 :
    • Extension de AMD-V 2.0 avec Rapid Virtualization Indexing (RVI)
  • 2013 :
    • Introduction de Docker pour la conteneurisation, qui rassemble plusieurs technologies existantes (jails, cgroups, namespaces…)
  • 2019 :
    • VirtualBox 6.1 supprime définitivement le support de la virtualisation logicielle, nécessitant désormais VT-x/AMD-V
  • 2020 :
    • Mode Dom0less pour Xen dans les systèmes embarqués
    • Intégration native de virtio dans tous les hyperviseurs modernes
  • 2021 :
    • Émergence des microVM et convergence conteneur/virtualisation

Références académiques et industrielles

  • 1 Protection ring. Wikipedia. https://en.wikipedia.org/wiki/Protection_ring
  • 2 Bugnion, E., Nieh, J., Tsafrir, D. (2017). The Popek/Goldberg Theorem. In: Hardware and Software Support for Virtualization. Synthesis Lectures on Computer Architecture. Springer, Cham. https://doi.org/10.1007/978-3-031-01753-7_2
  • 3 Popek, G. J., & Goldberg, R. P. (1974). "Formal requirements for virtualizable third generation architectures." Communications of the ACM, 17(7), 412-421. https://dl.acm.org/doi/10.1145/361011.361073
  • 4 Popek and Goldberg virtualization requirements. Wikipedia. https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
  • 5 Adams, K., & Agesen, O. (2006). "A comparison of software and hardware techniques for x86 virtualization." ACM SIGPLAN Notices, 41(11), 2-13. ASPLOS 2006. https://pdos.csail.mit.edu/6.828/2018/readings/adams06vmware.pdf
  • 6 Bugnion, E., et al. (2012). "Bringing Virtualization to the x86 Architecture with the Original VMware Workstation." ACM Transactions on Computer Systems, 30(4). https://dl.acm.org/doi/10.1145/2382553.2382554
  • 7 Bellard, F. (2005). "QEMU, a Fast and Portable Dynamic Translator." USENIX Annual Technical Conference, FREENIX Track. https://www.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf
  • 8 "QEMU." Wikipedia. https://en.wikipedia.org/wiki/QEMU
  • 9 Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., ... & Warfield, A. (2003). "Xen and the art of virtualization." ACM SIGOPS Operating Systems Review, 37(5), 164-177. SOSP 2003. https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf
  • 10 Lavania, K. K., Gupta, M., Jain, N., & Sharma, S. (2011). "Next-Generation Secure Computing Base (NGSCB)." Journal of International Academy of Physical Sciences, 15(2), 445-453. https://www.iaps.org.in/journal/index.php/journaliaps/article/view/657
  • 11 Anderson, R. (2003). "Cryptography and competition policy: issues with ’trusted computing’." PODC ’03: Proceedings of the twenty-second annual symposium on Principles of distributed computing, 3-10. https://www.research.ed.ac.uk/en/publications/cryptography-and-competition-policy-issues-with-trusted-computing
  • 12 "x86 virtualization." Wikipedia. https://en.wikipedia.org/wiki/X86_virtualization
  • 13 Fisher-Ogden, J. "Hardware Support for Efficient Virtualization." UCSD Technical Report. https://cseweb.ucsd.edu/~jfisherogden/hardwareVirt.pdf
  • 14 "Understanding Hardware-Assisted Virtualization." Admin Magazine. https://www.admin-magazine.com/Articles/Hardware-assisted-Virtualization
  • 15 Goto, Y. (2011). "Kernel-based Virtual Machine Technology." Fujitsu Scientific & Technical Journal, 47(3), 362-368. https://hobby.esselfe.ca/docs/KVM-tech.pdf
  • 16 Kivity, A. (2007). "kvm: the Linux Virtual Machine Monitor." Ottawa Linux Symposium, 225-230. https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf
  • 17 "KVM: Kernel-based Virtualization Driver." Qumranet White Paper. https://docs.huihoo.com/kvm/kvm-white-paper.pdf
  • 18 "dom0less." Xen Project Documentation. https://xenbits.xen.org/docs/unstable/features/dom0less.html
@misc{Clauzel:2025:Breve-histoire-des-technologies-de-virtualisation-Xen-VMware-KVM-et-QEMU,
	title = {Brève histoire des technologies de virtualisation : Xen, VMware, KVM, et QEMU},
	year = {2025},
	month = oct,
	day = 17,
	url = {https://damien.clauzel.eu/post/2025/10/17/Bre%CC%80ve-histoire-des-technologies-de-virtualisation-%3A-Xen%2C-VMware%2C-KVM%2C-et-QEMU},
	author = {Clauzel, Damien},
	language = {french},
	keywords = {virtualisation, processeur, chronologie},
	language = {french},
	abstract = {L’évolution des technologies de virtualisation sur architecture x86 représente l’un des aspects les plus significatifs de l’informatique moderne. Son histoire illustre comment les contraintes architecturales du processeur x86 ont conduit au développement de nouvelles solutions, puis de nouveaux paradigmes. Les quatre technologies abordées ici — Xen, VMware, KVM et QEMU - ont chacune apporté des approches distinctes pour résoudre les problèmes fondamentaux de la virtualisation x86. L’aboutissement actuel étant l’informatique par l’approche du nuage.}
}

Notes

[1] On va laisser de côté Hyper-V, hein. Ça sera mieux pour tout le monde 😛

[2] je vous renvoie à la 4e déclinaison du latin pour la signification et la prononciation

aucun rétrolien

vendredi 4 août 2023

Le moulin à café USB et l’informaticien

Par Damien Clauzel, vendredi 4 août 2023. Idées et réflexions

Nous sommes en 2023, et j’ai l’impression que de plus en plus les petits appareils électroménagers passent à une alimentation USB-C. Aujourd’hui, c’est mon nouveau moulin à café qui prend place dans la cuisine, y portant à trois le nombre d’appareils alimentés de cette façon — avec ou sans batterie.

Et honnêtement ? Cela me plaît beaucoup, car la connectique est standardisée et la puissance électrique est suffisante (jusqu'à 240W désormais). Également, le courant continu en très basse tension est bien adapté à ce type d’équipements, grâce à des pertes en ligne moindres comparées à celles en courant alternatif.

Un problème subsiste cependant : la prolifération des chargeurs sur les prises électriques. Ils prennent de la place, sont parfois de qualité médiocre (ou dangereuse…), ont une performance énergétique abyssale, etc. Bref, il est plus intéressant d’acheter un bon adaptateur secteur/USB ; mais le prix est un peu dissuasif.

La solution réside par la modernisation des installations électriques, avec un transformateur USB installé dans le coffret électrique du foyer (à côté de la Freebox !) pour alimenter toutes les pièces. Des modules sur rail DIN peuvent aussi être intégrés dans le tableau électrique, mais attention à la chaleur dégagée (eh, 240W on a dit). On rejoint la logique d’infrastructure réseau avec le PoE pour alimenter les équipements de périphérie.

La prolifération des pieuvres USB est un phénomène à combattre : elles sont moches, dangereuses pour la sécurité, peu performantes, et encombrantes. Et pire encore, Alsa 🐈 joue occasionnellement avec : s’ensuit alors un drame domotique.

 

Pieuvre USB
Multiprise USB avec moultes câbles branchés dessus

aucun rétrolien

vendredi 10 mars 2023

Il y a vraiment un problème dans la galaxie StackOverflow

Par Damien Clauzel, vendredi 10 mars 2023. Idées et réflexions

Il y a vraiment un problème dans la galaxie StackOverflow, que l’on voit monter depuis une paire d’années.

Je faisais cet après-midi du triage dans les files de modération des nouvelles questions & réponses, et j’y aie vu (comme d’habitude) des soumissions datant de ~20 minutes avec des scores de -2 ou pire.

Pourtant les demandes sont bien rédigées, étayées, sourcés, pertinentes, et tout. Mais non, blam, elles se font enterrer à cause de leurs scores, sans justification des personnes qui les basvotent. Les nouveaux utilisateurs ayant posé ces questions ne recevront alors jamais de réponses, sauf si on redresse manuellement leurs statuts.

C’est très problématique pour ces nouveaux utilisateurs — qui sont donc des juniors dans leurs domaines respectifs — se faisant ainsi torpiller.

Nous enseignons aux élèves de s’appuyer sur les communautés de pratiques, et des utilisateurs de ces communautés font un barrage à l’entrée pour diverses raisons (trop longues à commenter ici). C’est moche.

aucun rétrolien

mercredi 4 septembre 2019

Personnaliser l’écran de connexion d’un serveur Linux

Par Damien Clauzel, mercredi 4 septembre 2019. Informatique

Quand un serveur Linux démarre, on aime savoir qui il est et comment s’y connecter. C’est surtout vrai dans le cas de mise en réseau par DHCP ainsi que pour les machines virtuelles dans le cloud. Le désespoir est grand on voit la console afficher « Debian GNU/Linux buster/stable Clauzel.eu tty1 » mais qu’on a aucune idée d’où se connecter par ssh.

La solution est d’enrichir le fichier /etc/issue pour demander l’affichage d’informations supplémentaires. Ainsi, la configuration

Nom d’hôte : \n.\o
IPv6 : \6
IPv4 : \4
Système : \S{PRETTY_NAME} \s \m \r

produira l’affichage

Nom d’hôte : Clauzel.eu
IPv6 : 2a01:4f8:1c17:4608::42
IPv4 : 88.99.35.242
Système : Debian GNU/Linux 10 (buster) Linux x86_64 4.19.0-5-amd64

Remarques :

  • ici la balise \6 affichera uniquement la première adresse IPv6 de la première interface. C’est ennuyeux puisque l’IPv6 permet justement de disposer de nombreuses adresses ;
  • il est possible de choisir quelle interface on souhaite afficher, avec \6{eth0}, mais là encore on ne récupère que la première adresse ;
  • il est fort possible que cette solution ne fonctionne pas correctement avec systemd ; mais en même temps, qui utilise systemd sur ses serveurs ?

Documentation : man 8 getty

un commentaire aucun rétrolien

mardi 5 février 2019

Utiliser Steam sur un Chromebook

Par Damien Clauzel, mardi 5 février 2019. Informatique

Manipulation réalisé le 2019-02-05 sur un ordinateur Acer Chromebook Spin 11 R751T-C8D8.

Le prérequis est naturellement d'avoir un appareil compatible.

Dans les préférences de ChromeOS, activer les application Linux. Puis lancer le terminal pour installer le client Steam :

sudo apt update
sudo apt install wget
wget https://steamcdn-a.akamaihd.net/client/installer/steam.deb
sudo apt update
sudo dpkg -i ./steam.deb
sudo apt -f install
rm -f steam.deb
steam

Une nouvelle fenêtre de terminal va alors s'ouvrir, avec dedans l'installation de nouveaux paquets. Accepter l'installation.

Note : sur certains Chromebooks, il peut être nécessaire de positionner la variable d'environnement CPU_MHZ="2300.000" avant de lancer le client Steam :

CPU_MHZ="2300.000" /usr/bin/steam

aucun rétrolien

lundi 20 août 2018

Interview pour Le Progrès : « Challenger de Facebook aux USA, Reddit peut-il s’imposer en France ? »

Par Damien Clauzel, lundi 20 août 2018. Communication

Sébastien Jullien, journaliste au Progrès de Lyon voulait préparer un sujet sur Reddit afin d'apporter un coup de projecteur sur ce réseau social encore méconnu en France, et m'a demandé de répondre à quelques questions concernant Reddit et mon activité de modérateur.

Reddit est une plate-forme sociale, permettant de créer des communautés thématiques (hobby, technique, localisation géographique, etc). J'anime entre autre depuis plusieurs années la communauté grandlyonnaise : r/Lyon

@article{Clauzel:2018:Challenger-de-Facebook-aux-USA-Reddit-peut-il-s-imposer-en-France,
  title = {Challenger de Facebook aux USA, Reddit peut-il s’imposer en France ?},
  journal = {Le Progrès},
  year = {2018},
  month = aug,
  day = 20,
  url = {https://damien.clauzel.eu/Publications/Documents/Divers/2018-08-21%20-%20Challenger%20de%20Facebook%20aux%20USA,%20Reddit%20peut-il%20s%E2%80%99imposer%20en%20France%20%3f.png},
  url = {https://damien.clauzel.eu/post/2018/08/20/Interview-pour-Le-Progr%C3%A8s-%3A-%C2%AB-Challenger-de-Facebook-aux-USA%2C-Reddit-peut-il-s%E2%80%99imposer-en-France-%C2%BB},
  author = {Clauzel, Damien and Jullien, Sébastien},
  keywords = {Lyon, Reddit, réseau social, Le Progrès, r/Lyon},
  language = {french},
  abstract = {Momentanément passé devant Facebook aux Etats-Unis en février dernier, le site communautaire Reddit peine à exister en France. Mais, au fait, qu’est-ce que Reddit ?}
}

aucun rétrolien

mercredi 20 septembre 2017

Déployer un nœud YaCy sur une adresse IPv6 et avec un accès https

Par Damien Clauzel, mercredi 20 septembre 2017. Informatique

Il est possible de mettre en place un nœud YaCy participant à la fédération globale, avec une connectivité IPv6 et HTTPS.

Qu’est-ce que YaCy ? Facile.

YaCy est un moteur de recherche que chacun peut installer pour indexer le web (pages publiques accessibles par internet), pour indexer un intranet ou pour parcourir d'autres données avec une fonction moteur de recherche. YaCy peut être utilisé de façon autonome, mais sa principale force est de pouvoir fonctionner en réseau peer-to-peer, ce qui fait que sa puissance s’accroît avec le nombre d'utilisateurs, qu'il est entièrement acentré (tous les "peers" sont égaux et il n'y a pas un organisme administratif central) et qu'il n'est pas censurable et ne stocke pas le comportement des utilisateurs.

La liberté de l'information ainsi obtenue par le biais des logiciels libres et d'un moteur de recherche distribué est également un des objectifs du projet.

Prérequis

  • avoir une connexion IPv6 opérationnelle avec une adresse publique (nous utilisons ici 2001:41d0:12a:4d00:dcdc::46)
  • disposer d’un nom de domaine (nous créerons ici le champ AAAA YaCy.Clauzel.eu)
  • utiliser Debian/stretch sans systemd
  • avoir apache2 en place (nous ajouterons 2 vhosts)
  • avoir un certbot récent, celui de Debian/stretch est trop ancien et ne gère pas les demandes pour un hôte uniquement en IPv6 :
apt-get install certbot apt-get install certbot
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

Mise en place du nom de domaine

  • Créer l’enregistrement DNS pour le nœud; ici YaCy.Clauzel.eu pointe sur 2001:41d0:12a:4d00:dcdc::46

Installer YaCy

Mise en place initiale :

  • Lire et appliquer la documentation de YaCy ; nous utilisons ici la version 1.92 pour linux. YaCy est installé pour l’utilisateur dédié yacy:yacy dans le répertoire /home/yacy
  • Dans l’interface web de YaCy Mode d'utilisation et compte>avec SSL, activer le HTTPS sur le port 8443
  • Dans l’interface web de YaCy Administration du système>Paramètres d'accès au serveur>staticIP, définissez l’adresse publique du nœud comme étant YaCy.Clauzel.eu

Indiquer à java que nous donnons la préférence à l’IPv6 :

service yacy stop

Dans /etc/init.d/yacy, modifier JAVA_ARGS="-server -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Dsolr.directoryFactory=solr.MMapDirectoryFactory -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true"

service yacy start

À ce moment, YaCy doit tourner en mode Senior et être publiquement joignable à l’adresse http://YaCy.Clauzel.eu:8090

Créer le certificat TLS

Un simple certificat TLS suffit, mais vous pouvez vous faire plaisir avec les options :

service apache2 stop
certbot-auto certonly --standalone -d YaCy.Clauzel.eu --renew-by-default --must-staple --staple-ocsp --agree-tos --uir --hsts
service apache2 start

Préparation du certificat pour java

Les applications java ont ceci de casse-pied particulier qu’elles n’utilisent pas les certificats TLS au format PEM : il nous faut convertir notre certificat.

openssl pkcs12 -export -in /etc/letsencrypt/live/yacy.clauzel.eu/fullchain.pem -inkey /etc/letsencrypt/live/yacy.clauzel.eu/privkey.pem -out /etc/letsencrypt/live/yacy.clauzel.eu/yacy.clauzel.eu.p12 -CAfile /etc/letsencrypt/live/yacy.clauzel.eu/chain.pem -caname root -password pass:JeSuisUnMotDePasse -name yacy.clauzel.eu
keytool -importkeystore -srcstorepass JeSuisUnMotDePasse -deststorepass JeSuisUnMotDePasse -destkeypass JeSuisUnMotDePasse -srckeystore /etc/letsencrypt/live/yacy.clauzel.eu/yacy.clauzel.eu.p12 -alias yacy.clauzel.eu -srcstoretype PKCS12 -destkeystore /etc/letsencrypt/live/yacy.clauzel.eu/yacy.clauzel.eu.key

Mettre en place le certificat

Nous pouvons alors placer notre joli certificat dans l’arborescence de l’application.

service yacy stop
 cp /etc/letsencrypt/live/yacy.clauzel.eu/yacy.clauzel.eu.key DATA/SETTINGS/
 chown yacy:yacy DATA/SETTINGS/yacy.clauzel.eu.key
 chmod 400 DATA/SETTINGS/yacy.clauzel.eu.key

Configurer l’utilisation du certificat

Il reste maintenant à informer l’application de l’existence de ce certificat. Il faut vérifier/définir dans le fichier DATA/SETTINGS/yacy.conf :

port.ssl=8443
keyStore=DATA/SETTINGS/yacy.clauzel.eu.key
keyStorePassword=JeSuisUnMotDePasse
server.https=true
staticIP=YaCy.Clauzel.eu

Puis démarrer YaCy :

service yacy start

À ce moment, YaCy doit être publiquement joignable à l’adresse https://YaCy.Clauzel.eu:8443

Définir des redirections dans apache

Nous ajoutons alors des redirections web, qui permettrons d’accéder directement au nœud sans devoir spécifier le port.

Créer la directive /etc/apache2/sites-available/00-YaCy.conf :

<VirtualHost *:80>
    Define INSTANCE yacy.clauzel.eu
    ServerName ${INSTANCE}
    RewriteEngine On
    RewriteRule ^(.*)$ https://${INSTANCE}:8443 [redirect=301]
</VirtualHost>

<VirtualHost *:443>
    Define INSTANCE yacy.clauzel.eu
    ServerName ${INSTANCE}
    RewriteEngine On
    RewriteRule ^(.*)$ https://${INSTANCE}:8443 [redirect=301]
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/${INSTANCE}/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/${INSTANCE}/privkey.pem
</VirtualHost>

Activons cette configuration :

a2ensite 00-YaCy.conf
service apache2 restart

YaCy est désormais accessible à l’adresse https://YaCy.Clauzel.eu, et http://YaCy.Clauzel.eu redirige le visiteur vers l’accès sécurisé

Bonne chance à tous, comme on dit « chez-moi ça marche ».

9 rétroliens

dimanche 4 septembre 2016

Utiliser Steam sur MacOS en 2016 avec un système de fichiers sensible à la casse

Par Damien Clauzel, dimanche 4 septembre 2016. Informatique

En 2016 , le client Steam sur Mac a beaucoup changé par rapport à ce qu’il était en 2010. Enfin, pas tant que ça… Il est toujours en 32 bits, exige toujours un système de fichiers non sensible à la casse, son overlay est toujours aussi problématique, et sa gestion des manettes de jeu toujours aussi erratique.

Bref, il convient d’adapter la procédure que nous avions mis en place en 2010. Le principe reste le même : on mets tous les éléments dans une image disque, et on crée des liens.

Ouvrir un terminal

Nous allons travailler principalement en ligne de commande. Eh, jouer se mérite un peu ;) On pourrait faire la même chose en utilisant des outils graphiques, mais cela serait plus long à expliquer.

Créer l’image disque qui accueillera Steam

L’image disque peut être rangée n’importe où : /Applications, $HOME, etc. Nous la mettrons dans $HOME/Applications/Jeux

mkdir -p ~/Applications/Jeux
cd ~/Applications/Jeux
hdiutil create -size 50g -type SPARSEBUNDLE -fs HFS+J -volname Steam Steam
created: /Users/USER/Applications/Jeux/Steam.sparsebundle

Pour d’informations, on se tournera vers le billet sur la manipulation des images disques.

Mettre en place l’application Steam

Ouvrir notre image disque pour Steam et y copier l’application Steam fournie par Valve.

hdiutil attach Steam.sparsebundle
/dev/disk4          	GUID_partition_scheme          	
/dev/disk4s1        	EFI                            	
/dev/disk4s2        	Apple_HFS                      	/Volumes/Steam

On constate ici que notre image disque a été montée dans /Volumes/Steam; elle apparait d’ailleurs sur le bureau. Il suffit maintenant d’y copier l’application Steam de Valve directement depuis l’image d’installation.

Adapter le compte utilisateur pour faire fonctionner Steam

Le principe est de stocker dans notre image disque tout ce qui a trait à Steam, et d’utiliser des liens pour maintenir les chemins d’accès.

mkdir -p /Volumes/Steam/Library
# copiez dans /Volumes/Steam/Library votre dossier applicatif « Steam » existant; ou vous pouvez simplement laisser Steam le recréer… et retélécharger tous vos jeux.
ln -s /Volumes/Steam/Library/Steam ~/Library/Application\ Support/Steam

Il ne reste plus qu’à synchroniser le tout et à refermer.

sync
hdiutil detach /Volumes/Steam
"disk4" unmounted.
"disk4" ejected.

Jouer !

Pour utiliser Steam, il suffit de monter l'image disque (en double cliquant dessus, par exemple), puis de lancer l'application.

un commentaire aucun rétrolien

- page 1 de 16